Virtual machine backups may contain a plurality of volumes associated with different file systems. The volumes may be used for different purposes and one or more volumes may not require backup. For example, a swap partition may not require a backup. Additionally, restoration processes or servers may require volume information in order to permit granular restoration. A backup process or server may view a virtual machine backup as a file and may not be able to identify different volumes in the virtual machine backup. The lack of visibility into a virtual machine backup may prevent exclusion of volumes from backup resulting in the backup of unnecessary volumes (e.g., swap space). The lack of visibility may also prevent a restoration process from providing granular restoration. A restoration server may be able to mount backed up disks in order to identify the composition of volumes (e.g., operating system type, mount points, drive letters, offset, GUID, etc.). However, in order to mount a backed up disk, the server attempting to mount the disk must have a file system compatible with the disk. For example, a Windows backup server may only be capable of mounting disks with Windows compatible file systems. Additionally, mounting the disks requires resources from a backup server. Capturing volume composition information at each virtual machine to allow granular backup and restoration would require an agent running on each virtual machine. This would add a load to each virtual machine.
In view of the foregoing, it may be understood that there may be significant problems and shortcomings associated with current virtual machine backup management module technologies.